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(57) Abstract 

A technique for distributing software in a computer system, the software being comprised of software entity instances and 
the computer system being comprised of hardware entity instances, the technique comprising the storage of data in a database de- 
scriptive of the software entity instances, hardware entity instances, and relationships between such instances; the modification of 
one or more software entity instances; the scanning of a database to associate with each modified software entity instance one or 
more hardware entity instances to receive each modilied software entity instance; and the distribution of each modified software 
entity instance to one or more assodated hardware entity instances. The model upon which the database is built describes all 
hardware and software entity instances, as well as the relationships bctweeu such entity instances whid are significant to sof- 
tware distribution — 
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SOFTWARE DISTRIBUTION SYSTEM 
Field of tilie Znventiion 

This invention relates to multiprocessor computer 
5 systems and in particular to the distribution of updated 
versions of software to particular processors within 
such systems. 

Backgroiind of the Invention 

Traditionally, there have been two basic hardware 
10 conf igxiratiojis employed in the design of computer 
systems for multiple users. The first of these 
configurations includes a central processing unit, 
sometimes referred to as a "mainframe," connected to a 
plurality of user input/ output terminals. Each user 
15 input/output terminal is typically comprised of a 
keyboard for data entry and a cathode-ray tube or 
printer for data display. 

The other of these two basic hardware configurations is 
comprised of a number of individual processor units or 

20 "nodes", one for each user or small group of users, 

connected in a network. The network, which cam. serve to 
connect nodes separated by large geographic distemces, 
allows the sharing of software and data among users. 
Each node in the system may be connected to one or more 

25 input/ output terminals. In networks such as this, there 
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may also be an additional node or nodes not dedicated to 
a particular user- wHich may control one or more 
centralized databases Cor storing and retrieving data 
and software for tHe various users whose nodes are 
S connected to the network. Furthermore, an additional 
node aay be used by computer system overseers or 
"operator- personnel who monitor and control the 
operation of the network. Typically, such additional 
nodes also have input/output terminals connected to 
10 them. This "networked- system of multiple nodes has 
gained wide acceptance today. 

The acceptance of the multinode networked system is 
generally based upon the proliferation of "micro" or 
"personal" computers in the business and technical 
15 fields. These computers provide each user of a 

multinode system with dedicated computer power necessary 
to perform his business or technical functions, with a 
micro-computer node dedicated to his use, a user can 
perform his business or technical tasks more efficiently 
20 and easily. Zn addition to dedicated micro-computers 
such systems often include mainframes for, among othe^ 
things, database-related processing, and mini- or 
super-mini-computers to perform real-time processing. 



25 



The software employed in computer systems, whether of 
the first or second type hardware configuration 
described above, can generally be classified into one of 
two main categories. First, there is the so-called 
"operating systems software." Operating systems 
software is concerned with controlling the basic 
operation of a computer processor and/or system for 
input/output tasks, as well as memory-access tasks. In 
addition, operating systems software controls the 
execution of other computer programs. These other 
computer programs comprise the other main category of 
35 software, termed "applications software." Applications 
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sofliware ^typically performs a specialized technical or 
buslness-rela-ted function with which a user Is 
concerned. 

Softwsore, whether of the operating systems or 
5 application vsuriety, is often con^rised of many 

interrelated constituent computer programs. Constituent 
progreuns generally form a "software hierarchy" with 
"executive" programs controlling or directing the 
operation of "subordinate" programs within the 

10 hiereirchy. The reuige of hierarchical structures for 

software is almost limitless. For example, there can be 
one or more "executive" programs, each controlling the 
execution of (or "calling") one or more subordinate 
programs. These subordinate programs or "subroutines" 

15 can call subordinate programs of their own, and so on. 
There may be mcoiy levels of subordinated constituent 
programs in a hierarchy. Generally, the lower the level 
of a progrzon in a hierarchy, the more elemental its tas]c 
or function. Those programs which call one or more 

20 subordinate programs generally perform more complex 

tasks which are, in effect, amalgams of more elemental 
tasks performed by called subordinate progrsuns. With 
applications software, there is often more than. one 
hierarchy of progreims associated with the application. 

25 Applications software can be thought of as accomplishing 
a business or technical "function." A function, in 
turn, is comprised of one or more "processes." It is a 
"process" which is comprised of one or more hierarchies 
of programs. Because a program hierarchy is generally 

3 0 responsible for performing a certain task, a process can 
therefore be viewed as a logical subdivision of a 
business or technical function. 

In the multlnode computer system context, am application 
may be executed on more than one node. When constituent 
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processes of am appXica-bion execu^ in a paraXlel 
fasliion on separa-be nodes in tlie system ( i,a, , 
simultaneous execution of peurts of tlie application on 
multiple nodes) , the application is said to be processed 
5 in a ^distributed" fasliion. Hhen processes of an 
application execute in a serial fashion on separate 
nodes in the system ( i>e« , execution such that a g^iven 
node is the only node in the system executing an 
application process at a given time) , the application is 
10 said to be processed in a "cooperative" fashion. 

In many multinode systems, some of the nodes or groups 
of nodes ajre intended to execute identical processes or 
groups of processes. For example, an airline may find 
it desircdDle to have identical software executed on the 

15 varioxis nodes which run its application for taUcing 
airline reservations. Identical software may be 
necessary so that the users of the system, the airline 
reservation clerics or ticket agents , can provide the 
same services to prospective passengers regardless of 

20 which clerk or ticket agent is approached by the 
prospective passenger. 

Often, however, such systems have other nodes which 
execute distinct processes for distinct purposes v For 
example, an airline's applications software may not only 

25 have a ticketing/ reservation process, but also a process 
useful for trac3cing baggage. In both the distributed 
and cooperative processing contexts, specific nodes in 
the airline's multinode system may perform only the 
baggage tracking process. Furthermore, it may be 

30 useful for some nodes within a system to execute 

softwsure which performs more than one process. Such 
nodes would therefore execute the necessary groups of 
processes. in the above example, these nodes would 
execute both the ticketing and baggage tracking 

35 processes. 
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As s^-ted above, each applxcat:ion is usually made up of 
many Individual processes comprised of liiersLrchies of 
computer programs • Some of the individual processes 
within a function and some of the individual programs 
5 vithin a process may be sheared eunong several functions 
and processes^ respectively. This overlap most often 
occurs with lower level processes and programs within 
software hierarchies. For example, both ticket 
reservation ajid baggage traclcing fxanctions may require a 
10 process or program to write information to a database 

for subsequent retrieval. Such a process or program may 
not be dependent on the type of data stored. Thus, both 
functions may use the seune process or progrreim to support 
the accomplishment of their tas3cs. 

15 Often, applications software may reqpiire alteration 

because of the need to correct errors in program code or 
the need to include enhancements to a particular process 
within an application. However, because many programs 
share data resources, many processes shcire programs, and 
20 many nodes share processes, a programmer maJcing a 

needed alteration to a process' constituent program or 
programs is likely tmaware of (l) all programs and 
processes he is affecting by his alteration, and (2) 
which nodes in the multiprocessor system will require a 
25 copy of his updated or altered software program or 
programs . 

Thus, there is a need to determine all programs and 
processes affected by changes to individual progrsuns so 
that particular nodes which execute the affected 
processes can be identified. In addition, there is the 
need to physically distribute the updated versions of 
programs to the individual nodes of the network which 
execute the affected processes. In the past, these 
needs were accomplished by an individual or individuals 
who , manually determined all programs and nodes affected 
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by procpram alterations and the identity of the nodes in 
the system which executed the affected processes. 
Purthenaore, such individuals had to physically 
transport updated versions of the programs generally 
stored on a con^mter disk (typically a "floppy disk") or 
tape, to the individual nodes for loading into 
associated joemories. Even for small networks, where 
nodes are located in relatively close proximity to each 
other, the determination of affected programs and 
processes and the installation of updated versions of 
processes can be cumbersome at best. But, with larger, 
more complex networks executing many applications having 
many functions and processes, and with the possibility 
of large geographic distances between nodes in such 
networks, the difficulties associated with determining 
all affected processes and the logistical problems 
associated with the physical distribution of updated 
software can be highly burdensome, if not impossible as 
a practical matter. 

20 Summary of the Invention 

These problems are solved by the present invention which 
is a software distribution system (SDS) for distributing 
software programs to particular nodes in a multinode 
system. One aspect of the SDS is a relational database 

25 which contains information which relates an application 
to its associated data entities and its associated 
processes, and which relates processes to individual 
nodes in a multinode computer network, whether of the 
distributed or cooperative type. Another aspect of SDS 

30 fxirther provides a processing means (or node) , 

associated with the database, for determining each 
program and process affected by an alteration to a 
program and the identity of all nodes in the network 
which execute the affected processes. SDS also provides 

35 a warehouse database for storing software to be 
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dls-tribu-ted, and a dis-tzribu-bion channel for delivering 
any al^tered programs -to iden-tified nodes wiUidLn *btie 
mxil'tinode ne^ork. 

The database aispec^ of SDS is built according -to an 
5 enti1r/**relationsliip model which defines certain logical 
entities and relationsbxps among such entities. These 
entities specify the elements of a multinode system, 
including its heurdware, softwaure emd data. The entities 
provided by the dateUbase portion of SDS include 

10 **Wor]cstations'' (which are nodes and associated 

input/ output devices)^ "Processes," "Programs," "Data," 
and "Releases" (which are logical units of work to be 
distributed by SDS) . The relationships among entities 
are also defined by the database of SDS emd include a 

15 "Workstation to Process" relationship, associa-ting a 

node to a Process to which it has access ; a "Release to 
Process" relationship, associating a given Release with 
a given Process; a "Release to Program" relationship, 
associating a given Program with a given Release; and a 

20 "Release to Data" relationship, associating a given 
Release with given Data. 

The processing means aspect of SDS using the above 
described database operates to determine all entities 
which are affected by ant update or chsmge to a given 
25 progreun or data. Either the seu&e or another processing 
means controls the trsmsmission of identified software 
or data from the warehouse database to the appropriate 
Workstations for installation thereon. 

Brief Description of the Drawincrs 

30 Figure 1 is em illustration of a three-tiered computer 
system. 

Figure 2 is eui illustration of a two-tiered computer 
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sys-tea. 



Figure 3a is a diagraaanatic representation of an 
entity-relationsHip aodel according to the present 
invention. 

5 Figure 31d is a diagraamatic representation of an 
entity-relationship model according to the present 
invention. 

Figure 3c is a diagrannnatic representation of a portion 
of the contents of a database constructed according to 
10 an entity-relationship model illustrated in Figure 3a. 

Figure 3d is a diagrammatic representation of a portion 
of the contents of a database constructed according to 
an entity-relationship model illustrated in Figure 3b. 

Figures 3e and 3f are diagrammatic representations of 
portions of databases constructed according to entity- 
relationship models illustrated in Figures 3a and 3b. 

Figure 4 is a diagrammatic representation of the entity 
and relationship instances associated with a release, as 
well as the migration path of modified entity instances 
20 being distributed. 

Detailed D escription of the Invention 

Typical hardware configurations for computer systems 
employing the present software distribution system 
invention (SDS) are depicted in Figures 1 and 2. Figure 
25 1 depicts a "three tiered" computer system, so named for 
its three levels of computer processors or "hardweure 
platforms." a "three tiered" system can be comprised, 
for example, of a mainframe computer 1, a mini- or 
super-mini-computer 2, and micro-computers and their 
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associated input/ output devices, collectively referred 
to as "worlcstations" 3. 

Typical processors preferred for eacb of these tiers are 
the IBM mainfrEme sold under the trade m a r k "Model 3090'», 
running the IBM MVS/XA operating system; the Stratus 
mini-computer sold under the trademark "Model XA2000", 
running the Stratus Coaster, Inc. VOS operating system, 
and the IBM micro-computer sold under the trademark 
"PS2", executing the Microsoft Corporation operating 
system sold under the trademark "MS-DOS." (For further 
information on these processors or their operating 
systems, the reader is referred to the "IBM System/370 
Bibliography", document mrntber GC20-0001; the "IBM 
Technical Directory", docxament number 6024448; and 
"Introduction to VOS", by Stratus Computer, Inc., 
document number ROD OX.) 

Each of these processors and workstations is a node in 
the network. The mainframe computer 1 is connected to 
and performs all processing associated with a datsdsase 

20 5, referred to as the "Repository." The Repository 5 is 
used to store a description of an application in terms 
of an SDS Entity-Relationship Model discussed below. 
The mainframe 1 may also be connected to a micro- 
computer with an input/ output (I/O) device 6 ( ±.&. , a 

25 workstation) , or simply an input/ output device. In 

either case, the purpose of this connection is to allow 
a human to access the Repository 5, as well as control 
mainframe 1 processing. The mini-computer 2 is 
connected to the mainframe 1 and to a datsQ^ase of its 

30 own, referred to as the "warehouse" 4. The warehouse 4 
is used to store all versions of all software programs 
and data which comprise a given application. Like the 
mainframe 1, the mini-computer 2 may also have a 
workstation or I/O device 6 for humsm access to the 

35 warehouse 4 and to control mdLni-computer 2 processing. 
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The mini-conputer 2 is furtlier connected to a one or 
More worlcstations 3. The conputear system (or network) 
can Have as many worlcstations 3 as would be desired to 
support user access to given applications software. 

Figure 2 depicts a "two tiered" counter system, so 
named for its two distinct levels of hardware platforms. 
UnliJce the three tiered system, the two tiered system 
includes only one platform in addition to its 
worlcstations 3. Typically, the two tiered system 
includes a mainframe 7, performing the work of both the 
mainframe l and mini-computer 2 of the three tiered 
system depicted in Figure i. The mainframe 7 of the two 
tiered computer system is connected to both a Repository 
database 5 and a Warehouse database 4, as well as a 
15 workstation or I/O device 6 for database access and 
processor control. As mentioned, the mainframe 7 is 
connected to a network of worlcstations 3. However, a 
processor of emother type coxild substitute for the 
mainframe processor 7 in the two tiered system, 
20 depending on specific through-put requirements and 

equipment availability. As is the case with the three 
tiered system, the processor and workstations of the two 
■tiered system aure nodes in the network. 

Regardless of whether the computer system of Figure 1 or 
25 Figure 2 is employed for the distribution and execution 
of applications software, the software and data to be 
distributed is maintained in the warehoxase 4. This 
software and data may be stored in executable form or in 
a soiirce code format. The information necessary to 
30 properly distribute such software is maintained by 
Repository 5, with the mainframes 1, 7 executing 
software necessary to determine what software must be 
distributed. Generally, the nodes which will receive 
software distributed by SDS are the workstations 3. 
35 However, sxxch workstations 3 could be replaced, by other 
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nodes of malnfirasie or mlni-compulrez- veurle^y, 

-themselves coxinecrted -to o1:heir nodes in a ne'tvork* Thus, 
the 5DS is nol: limited to the distribution of software 
solely to micro-computer-based workstations. Rather, 
5 SOS is suitedble 1:o distribute software and data -to amy 
node in the network. However, for clarity of 
explanation, this description will refer to all nodes in 
a system which are to receive distributed softwsure and 
data as Worlcstations • 

10 The SDS Entity-Relationship Model 

As indicated above, all information necessary to 
properly distribute updated portions of applications 
software f i.e. , a Release) to the appropriate 
Workstations 3 in the network is maintained by the 
15 Repository 5, which is a special-purpose relational 
database. 

A "relational database** is a term used to described a 
computer program which carries out the storage, 
searching and retrieval of data on a mass storage 

20 mediiua, such as a disk storage system. **Relational 

database** is also used to describe information stored on 
a disk storage system by a relational database program. 
A relational datadbase program stores, searches andL 
retrieves data according to specific commands from the 

25 database user. That is, with a relational database, a 
user specifies the data to be stored, the searching (or 
•■traversing**) of the datzQ^ase to be performed, andL what 
is to be retrieved by the database program. Relational 
database prograuos are well known and are available 

30 commercially. For purposes of a preferred embodiment of 
this invention, it is preferred that the IBM relational 
database sold under the trademark **DB2'* be employed. 
(For more background information on DB2, the reader is 
referred to the following IBM publications which are 
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Hereby incorporated by reference: -ibm DATABASE 2 
Introduction to SQI." (document nuaber GC26-4082) ; -ibk 
DATABASE 2 Reference" (document number SC26-4078) - 
-OS/VS2 TSO command I^guage Reference- (document 'number 
GC28-0646) ; «TSO Extensions Command Language Refereace- 
(document number SC28-1307) ; -Interactive System 
Productivity Facility/Program Development Facility for 
MVS: Program Reference" (document number SC34-2089) ; 
-Interactive System Productivity Facility/Program 
Development Facility for MVS: Dialog Management 
Services- (document number SC34-2137) ; and -DB2 
Application Programming Guide for TSO and Batch Users.") 

The Repository 5 maintains information on all elements 
Of a computer system which- are necessary for software 
distribution, as well as all necessary interaction among 
computer system elements. These elements (or 
"entities") and their interactions (or -relationships") 
are defined generally by an SDS Entity-Relationship 
Model, Which is the basis of information organization in 
the repository 5. The SDS Entity-Relationship Model 
thus provides the basis for all commands to a relational 
database program. The Model supplies the intelligence 
needed to create and maintain the Repository 5 via the 
relational database program, which is only a tool in the 
context of the present invention. 



The -entities- of the Model represent something real or 
abstract about which information is recorded in the 
Repository 5. This information is organized into a set 
Of characteristics known as "attributes." Entities 
30 Which share a common set of attributes are grouped into 
classes called "entity types." An "entity instance" is 
a specific occurrence of an entity type and is described 
by a set of specific attributes. 

The "relationships" of the SDS Entity-Relationship Model 
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specify an association be'tvean ent:i*bies. UJce en-blties, 
rela-tlonstilps aire described by *tbelr alr-bribu-tes • 
Relatlonsblps vl-tb cdnston a-t^trlbuHes eure referred tio as 
''relatlonsh 1 p types," vbile a ''relationsblp Instance" Is 
5 a specific occurrence of a relationship type and Is 
described by a set of specific attributes* 

The SDS Entity-Relationship Model therefore provides a 
representation of the oveirall logical structure and 
elements of softwaire generally In terms of specific 
10 entity and relationship instances definable through the 
Model • 

The entity types of the SDS Entity-Relationship Model 
are as follows: 

- "Workstations," which describe the 

15 physical workstations to which software 

must ultimately be distributed; 

- "Workstation Groups" which describe 
logical groupings of workstations; 

- "Release," which describes the logical 
20 iinlt of work to be distributed by SDS; 

- "Function," which describes a given 
application software package; 

- "Process," which describes a logic<il 
sxibdivision of a function; 

25 - "Program, " which describes an Individual 

software routine, either executive or 
subordinate, which forms a portion of a 
process ; 
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- "Data Entity," vhich describes a 
collection of data values wiiicti slt^ 
necessary for the operation of a program; 

- "Vaaue," wiiich describes a single static 
5 data item literally (either in integer, 

decimal or character formats) • 

The attributes associated with these entity types 
include an attribute which identifies discrete instances 
of such entities. Thus, the Repository 5 contains 
10 information identifying each Function, and each 

constituent Process, Program, and Data Entity, as well 
as each Worlcstation Group and WorJcstation, comprising 
the hardware and software of a given computer system. 

In addition to an identifier attribute, certain entity 
15 types have associajted with them additional attributes. 
Function attributes also include an Application ID 
attribute, which specifies the Applications Software in 
which a given Function instance is used. Program 
attributes also include an Execution Environment 
20 attribute, which specifies the hardware platform on 
which a given Program instance executes. Valuer 
attributes include the nximerical value of a given datum. 

In addition to entities and their attributes, SDS 
defines certain relationships among entities. These 
relationships are cilso incorporated in the SDS Entity- 
Relationship Model depicted in Figure 3a. The first of 
these is the "Refines" relationship 42. Refines 42 is 
used to describe the decomposition of Fiinctions 41 into 
Processes 43. The highest level or executive Process is 
Jmown as a "Root" Process (so known because other 
Processes branch out from it) . Refines 42 ' is also used 
to describe the decomposition of a Root Process into 
intermediate and lowest level Processes, known as "Node" 

eNsooao- <wo_9ioe*42Ai j_> 
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and "Leaf" Processes, respectively. When used to 
describe tlie decomposition o£ Functions 41 into 
Processes 43, Refines 42 represents the first step in 
the step-wise refinement of Functions 41 into executable 
5 Programs. 46. When used to describe the decoo^osition of 
a highest or higher level Process 43 into a lower or 
lowest level Process 43, Refines 42' represents a 
further step in the seune step-wise refinement. 

The attributes associated with the Refines 42, 42' 
10 relationship include the identification of the 

"participants" dLn the relationship. Specifically, there 
is the "First Participant" attribute, which identifies 
the Function/Process instances being refined, and there 
is the "Second Participamt" attribute, which identifies 
15 the Process instance immediately subordinate to the 
First Participsmt. 

Another of the relationships defined by SDS and 
incorporated into the SDS Entity-Relationship Model is 
"Defines" 44 • The Defines relatioiiship 44 is used to 

20 describe the relation between a Process 43 emd a Program 
46. Specifically, the relationship connects an instajice 
of the lowest level Process 43 (Leaf Process) to a 
Program 46. Generally, the Program 4 6 specified by the 
Defines relationship 44 is the highest level Program in 

25 the Leaf Process, and is known as a "Root" Program. 

Def dines 44 represents yet another step in the refinement 
of Functions 41 into Progrzuiis 46. 

The attributes associated with the Defines relationship 
44 include the identification of participants in the 
3 0 relationship. The First Participant attribute 

identifies the Leaf Process instance being defined, and 
the Second Participemt attribute identifies the highest 
level or Root Program instance of the Leaf Process. 
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Anotiier of the relationships defined by SDS auid 
incorporated into the SDS Entity-Relationship Model is 
"Uses" 45. The Uses relationship 45 describes the 
relation between one Program 46 and another* Uses 45 
5 relates a higher or highest (Root) level Program to a 
subordinate Program. It provides for the further step- 
wise refi n em en t of Functions 41 into Programs 46. 

The attributes associated with the Uses relationship 45 
include the identification of the participemts in the 
10 relationship. The First Participant attribute 

identifies the highest or higher level Program instance 
using the Second Participant attribute, the lower level 
Program instance. 

A further relationship defined by SDS and incorporated 
15 into the SDS Entity-Relationship Model is "Refers" 47. 

Refers 47 is used to describe the relationship between a 
Program 46 and an external Data Entity 48. A Program 46 
may Refer 47 to a Data Entity 48 by making a local 
declaration statement within the Progrcua 46 to the Data 
20 Entity 48. 

The attributes associated with the Refers relationship 
47 include the identification of the participants in the 
relationship. The First Participant identifies the 
Program instance requiring a reference to the Data 
25 Entity instance. The Second Part icipemt is the common 
identifier name for a collection of data Values, i,e. , 
the Data Entity instamce. 

Another of the relationships defined by SDS cuid 
incorporated into the SDS Entity-Relationship Model is 
30 "Members" 49. The Members relationship associates a 
Data Entity 48 to its individual member Values 50, 

The attributes associated with the Members relationship 
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49 include tlie identification of the participants in tlie 
relationship and a Symbol Name for the Second 
Participant. The First Psurticipant attribute identifies 
the common identifier neuae for the group of data Values 
5 ( i.e> , the Data Entity instance) . The Second 

Participemt attribute is an individual Value of data. 
The Symbol Name attribute is a symbolic n£une which can 
be used to refer to the Value of data identified by the 
Second Participant, without using the Value itself. 

10 Another of the relationships defined by SDS and 

incorporated into the SDS Entity^-Relationship Model is 
"Workstation Group To Process" 51. This relationship 
eissociates a Workstation Group 52 to the Process 43 to 
which it has access. 

The attributes associated with the Workstation Group to 
Process relationship 51 include the identification of 
the Participants in the relationship. The First 
Participant attribute identifies a Process instance. 
The Second Participeait attribute identifies the 
Wor3cstation Group instance having access to the First 
Participant. 

Another of the relationships defined by SDS and 
incorporated into the SDS Entity-Relationship Model is 
"Workstation To Wor3cstation Group" 53. The Workstation 
25 To Workstation Group relationship 53 defines the 

association between a Worlcstation 54 amd the Workstation 
Group 52 to which it belongs. 

The attributes associated with the Workstation To 
Worlcstation Group relationship 53 include the 
30 identification of the participsmts in the relationship. 
The First Participant attribute identifies the 
petrticular Workstation Group instance in question. The 
second Participant attribute identifies the Workstation 
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instsmce belonging to the First Participemt. 

Slioxild a given applications sodftware processing system 
not employ identifiable groxxpa of worlcstations , or, 
should it be undesirable to have identifiable 
5 workstation groups, the Repository 5 would not need the 
entity of Workstation Groups, nor the specific 
relationships of Workstation Group to Process or 
WorJcstation to Wor3cstation Group. Rather, etll that the 
Entity-Relationship Model of the Repository 5 would 
10 maintain would be a "Workstation to Process" 
relationship • 

The attributes associated with the Worlcstation to 
Process relationship include the participsmts in the 
relationship. The First Participant attribute 
15 identifies a Process instemce. The Second Participant 
attribute identifies the Workstation instance having 
access to the First Participant* 

Another of the relationships defdLned by SDS ajid 
incorporated into the SDS Entity-Relationship Model and 
20 referenced in Figure 5 is "Release To Process" 55. The 
Release To Process relationship 55 associates a. Release 
20 with a Process 43 affected by the Release 20. 

The attributes associated with the Release To Process 
relationship 55 include the participants in the 
25 relationship. The First Participant attribute 

identifies the Release instance in question. The Second 
Participant attribute identifies a Process instance 
affected by the First Participemt. 

Yet Mother of the relationships defined by SDS and 
30 incorporated into the SDS Entity-Relationship Model is 
"Release To Program" 56. The Release To Prograia 
relationship 56 associates a Program 18 to be 
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distributed by SDS in a particular Release with the 
Release 20 itself. 

The* attributes associated with the Releztse To Program 
relationship 56 include the identification of the 
5 participeints in the relationship. The First Participemt 
attribute identifies a Release instance. The Second 
Participant attribute identifies a given Program 
JLnstance to be distributed by SDS by the particular 
Release instance identified by the First Participant. 
10 Other attrdLbutes of the Release To Progreua relationship 

56 include a Program's Logical File Ncune. A Ijogical 
File Name is a function of both a Physical File Name 
(discussed below) eind a Release name. It allows 
different Releases to refer to different versions of the 

15 scune entity. Other attributes include a Physical File 
Ncime and a Path Name. A Physical File Name refers to a 
block of executable code, Eoid is an input to the Logical 
File Ncime generation process. A Physical File Neme will 
usually be the same as the xxamB of the entity ( i.e. , the 
20 identification attribute of an entity instance) , but can 
further dlnclude extensions should a given Progrsua be 
comprised of more than one file of execut2Q3le code. A 
Path Name refers to a high level portion of a disk 
address at a particular workstation where software will 
25 be stored once distributed emd installed. 

Another of the relationships defined by SDS and 
incorporated into the SDS Entity-Relationship Model is 
"Release To Data" 57. The Release To Data relationship 

57 is used to identify a Data Entity 19 to be 
distributed by SDS in a particular Release with the 
Release 20 itself. 

The attributes associated with the Release To Data 
relationship 57 include the identification of the 
participants in the relationship. The First Participant 
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attribute identifies tlie Release instsmce. The Second 
Participcmt attribute identifies a Data Entity instance 
to be distributed by SDS for the psurticular Release 
instance identified by the First Participant. Other 
5 attributes of the Release to Data relationship include a 
Data entity's LogicaJ. File Name which, as discussed 
above, is a function of both a Physical File Neune and a 
Release Name. As with the Release to Program 
relationship 56, attributes of the Release to Data 
10 relationship 57 include a Data Entity's Physical File 
Name and Path Name. 

Depending upon the overall nature of the computer system 
in which SDS is employed, it may be useful to define 
additional entities and relationships tailored to the 
15 system. For example, if there are particular or special 
types of programs defined for use in a certain computer 
system, entity types corresponding to these program 
types can be adopted for use in the Repository 5. 

Special Entities amd Relationships 
20 Defined by the SDS Entity-Relationship Model 

Often in various software applications in the bxasiness 
and technical fields, there 2ure special program/ I/O, 
and data related entities amd relationships which serve 
to enhance the operation and efficiency of software. 

25 For instajice, in the field of Computer-Aided Softweore 
Engineering (CASE) , which concerns specialized computer 
software which aids in the design suid/or coding of 
applications programs, special program types, data and 
interactions cimong programs smd data exist. Therefore, 

3 0 where CASE and other special software is concerned, the 
SDS Entity-Relationship Model tadces accoxint of special 
program types, data and interactions by further 
providing SDS entity and relationship types tailored for 
use with this special software. 
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Tlie first of these entities is the "Rule," A Rule is a 
special type of Program wiiicti provides the procedural 
specifications of the logic for a portion of a Process. 
In addition, a Rule can control, among other things, the 
5 execution of other Rules. Rules themselves are 

generally specified in a high level language referred to 
as "Rules Ismguage." Rules leinguage is typically not 
executable sotirce code, but rather "pseudocode" which in 
some ways resembles English and which can be readily 

10 tramslated into one of the msmy available computer 

source code languages. Rules language is based on the 
principles of structiared design and programming. Thus, 
with the Rules leuiguage, a designer of applications 
software aaji design Rules pseudocode to perform such 

15 structured constructs as "Do While," "Do Until," aind 
"If, Then, Else," for exeunple. Rules and the Rules 
language malce it generally possible for an applications 
software designer to design software without concern for 
the specific language which may be required by a 

20 specific processor node. This capability can be 

particularly useful in cooperative and distributed 
processing systems where an application may be executing . 
on several dispeurate nodes which employ various source 
code compilers. 

25 The attributes associated with the Rule entity type 

include an attribute for the identification of discrete 
instances of Rules, as well as an attribute specifying 
execution environment for the Rule instance. 

A second entity defined for CASE (or other special) 
30 softweore is the "Component." A Component is a block of 
computer instructions written in a soxirce code 
programming language. Components are used to perform 
the functions not hamdled by Rules. 
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The at-taribu-tes assoclatied with Componexilis include am 
attribute for the identification of discrete instances 
of Components, em attribute specifying execution 
environment for the Component instance, and an at^ibute 
5 specifying the source code language in which a Component 
instance is written. 

The next of these entities is the "Window." Windows cire 
a type of Progreun which define the man-macbine 
interface. They specify what data is to be accepted 

10 from a user, how it is to be displayed, and how it is to 
be accepted. In designing em application or portion 
thereof for execution on an "IBM PC," it is preferred 
that the Microsoft Corporation's Window program, sold 
under the trademark "MICROSOFT WINDOWS," be used. (For 

15 more backgroxand information on MICROSOFT WINDOWS, the 
reader is referred to the following Microsoft 
Corporation publications which are hereby incorporated 
by reference: "Microsoft Windows Programmer's Utility 
Guide" ; "Microsoft Windows Application Style Guide" ; 

20 "Microsoft Windows Programmer's Reference"; euid 
"Microsoft Windows Quick Reference.") 

The attributes associated with Windows include an 
attribute identifying discrete Window instances. 

For most systems, the only nodes capeible of executing 
25 Window entities are the Workstations, since they will 

usually be the only platforms which comprise a cathode- 
ray tube display in addition to a processor* As sucb, 
there is usually no need for an attribute describing the 
execution environment of the Window. However, should a 
30 particular computer system be configured to include 
cathode-ray tube displays connected to mainframe or 
mini-computer nodes, the SDS Entity-Relationship Model 
can be adapted to include for the Window entity the 
additional attribute of execution environment. 
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A fiirther of tihese enlii'kies is a "View.** A View is a 
logical collection of da*ta el entente (or "Fields** ais 
described below) • A view can also cozi^rise other Views* 
Essenltially, a View is a mul'biplici'ty of date vaoriables 
5 (or Fields - see below) and is parbicularly usefal for 
defining tee da1:a in*terf ace be-tveen one program and 
anoteer or from a sys1:em user to a program. The former 
type is referred to as a ''Module View" smd tee latter is 
referred to as a "Window View". 

10 The attributes associated wite Views include an 

identification attribute specifying discrete View 
instances . 

Anoteer of teese entities is a Field. Fields describe 
tee basic data elements teat comprise a business or 
15 technical data resource. A Field stores all information 
about data elements independent of tee environment in 
which tee data is actually stored. 

The attributes associated wite Fields include an 
identification attribute, for specifying discrete Field 

2 0 insteuices; a Field Format attribute, for describing tee 

format in which data is stored in memory ( e.g. , integer, 
decimal, character, etc.); and a Field Lengte attribute, 
for specifying tee size (or length) of a Field. 

For applications designed wite certain CASE software, 
25 tee higher level entities and relationships still apply 
(see Figure 3b) . That is, tee Function 41 and Process 
43 entities, as well as tee Refines 42, 42' emd Defines 
44' relationships, are a part of tee SDS Entity- 
Relationship Model and are used to described a software 

3 0 application in tee Repository 5. The only difference is 

wite respect to tee Defines relationship 44', which in 
tee CASE context is used to describe tee relation 
between a Process 43 and Rule 60. 
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The a-b-tirllDu^s of tiie Refines 42, 42^ emd Defines 44' 
rela^tlonslilps 2Lce *ttie same as defined prevloiisly. 

The Uses 3relat:lonslilp defined previously describe tiie 
relalrlonslilp be*tween Programs Is used in -the CASE 
5 con^esrb describe tihe rela-blonshlp between 1:wo Rules 
(61), a Rule emd a component (61'), and two Components 
(61") . (It Is preferred that a component not Use a 
Rule.) Tbe attributes of the Uses relationship 61, 61', 
61" are as defined previously. In tbe CASE context, it 
10 is pref earred that a Component not be a FdLrst Participant 
unless another Component is a Second Paurticipatnt in the 
relationship. 

A relationship not previously defined is "Converses" 62. 
Converses 62 is used to describe a Rule 60 coiuiecting to 
15 a Window 63. (It is preferred that a Rule Converse with 
only one Window) . Only those Rules which are resident 
in a node with axi I/O device Including a cathode-ray 
tube may Converse with a Window. 

The attributes of the Converse relationship 62 are the 
20 First and Second Participants. The First Participant 
attribute identifies the Rule Instance in question, 
while the Second Participant Attribute identifies its 
Window instamce . 

The "Owns" relationship 65 is iised to connect Rules 60, 
25 Components 64 smd Windows 63 with Views 68, thereby 

associating with a Rule 60, Component 64 or Window 63 a 
specific data Interface. 

The attributes of the Owns relationship 65 are the First 
Participant, the First Participant's entity type, the 
30 Second Participant, and the View Usage. The First 

Peurticipant attribute can be a Rule, Component or Window 
name ( i.e. , the identification attribute for a certain 
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Rule, Component or Window instance) . The First 
Participcint's entity type attribute will specify Rule, 
Component or Window. The Second Participant attribute 
will be the identification attribute for the View 
5 instamce petrticipating in the Owns relationship 65. The 
view Usage attribute will specify a directionality to a 
View ("In" for an Input View smd "Out" for an Output 
View for Rules and Components; "InOut" (bidirectional 
View for Windows as well as Rules and. Components) • 

10 The "Includes" relationship 67 is used to nest a View 
within another View, or to connect a View with its 
constituent Fields (67'). A View 68 may therefore 
Include a View 68 or a Field 69. 

The attributes associated with the Includes relationship 
15 67, 67' comprise the First Participant attribute (which 
is the View instance in q[uestion) ; the Second 
Participant attribute (which is either the nested View's 
or Field's identification attribute), the Second 
Participant's entity type (which would either be View or 
2 0 Field) ; the Sequence Number attribute (which indicates 
for a View that has nested Views and Fields the order of 
nested Views and Fields); and the Occurs Nujoaber of Times 
attribute (which indicates how many associations there 
sure between the First Participeuit View and Second 
25 Participant Views; this attribute will be zero for Views 
which Include only Fields) . 

Note that the Refers relationship 66 is similar to the 
Refers relationship 47 (see Figure 3a) in the general 
Model, but it associates either Rules 60 or Components 
30 64 to a Data Entity 48. As such the First Participant 
attribute in this relationship may include the 
identification attributes from either the Rule or 
Component instance in question. 
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Appllca1:lon of tne SDS Enti-ty-Relationsliip Model 
t:o Specific Softrvare and Hardware Conficmrations 

The application of ttie above-defined SDS Entity- 
Relationsliip Model to specific software and a computer 
5 system requires tnat tHe specifics of the software and 
the system be identified to the Repository 5 according 
to the specifications of the Model. That is, when 
designing a new application, a prograanmer can store in 
the Repository 5 a description or representation of the 

10 application suid haurdware as instances of the entity and 
relationship types provided by the Model. (For purposes 
of consistency, both the actual software and hardware of 
a computer system and the representation of such 
software and hardware on the Repository 5 will be 

15 referred as "entity instances." It will be clear from 
the context of discussion which is being referenced, 
actual software and hardware or their representation in 
the Repository 5. "Instances" are to be distinguished 
from "types", which form the SDS Entity-Relationship 

20 Model as discussed above) . 

When updates to an application are made, the Repository 
5, containing specific entity and relationship instances 
descriptive of the application and the related hardware, 
can be examined by SDS to determine information required 
25 for software distribution. 

However, the SDS Entity-Relationship Model described 
above has been designed to provide not merely for entity 
and relationship types which eire required for software 
distribution, but also a structure useful for orderly 
3 0 and logical applications software design. The design of 
the SDS Entity-Relationship Model thus achieves great 
efficiency since for a given software application the 
entity and relationship instances useful for software 
distribution caji in fact be stored in the Repository 5 
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as a na^iiral consequence of software design, requiring 
1 it-tie or no furtlier refinement for software 
distribution purposes ♦ This feature of the SDS Entity- 
Relationship Model can be quite useful when combined 
5 with CASE software designed for Entity-Relationship 
Model compatibility. Thus, with an automated auid 
compatible CASE tool, a designer can design software and 
build entity emd relationship instzmces in the 
Repository useftil for software distribution at the same 
10 time. 

The SDS Entity-Relationship Model is equally appliceUale 
to facilitate software distribution of applications 
written without the Model in mind. The structure of the 
SDS Entity-Relationship Model is generic enough to 
15 describe the specifics of amy application. All that 
need be done is to logically describe an existing 
program and computer system in terms of the categories 
of entities and relationships provided by the Model. 
Once this is done, the specific insteoices of such 
20 entities and relationships are stored in the Repository 
5 for future use in the distribution of modified 
software entity instances. 

Regardless of which system is employed to develop the 
entity and relationship instances for a given 
application, the result of such development is a 
Repository 5 containing a representation of entity and 
relationship information. This information is 
illustrated by way of example in Figure 3c. Regarding 
the instances of entities, note that a given application 
or Function instance 8 is logically composed of a 
highest level or Root Process instance 9, which intern 
is comprised of one or more lower level Process 
instances 10, 11. The lowest level Process instances 11 
fiure each comprised of a highest level or Root Program 
instance 12, which may call one or more subordinate 
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Program instances 13. Eacli of the subordinate Program 
instances X3 may in turn call other subordinate Program 
instances 14, and so on. Any of the Program instances 
may have access to or need for Data Entity instances 15 
5 which comprise individual data Value dLnstances 16. The 
relationship instetnces among the entity instances are 
indicated in the Figure. 

Iieaf Processes are the only Processes which directly 
relate to one or more programs/data entities. All other 

10 Processes (for example Root and Node Processes) are 
merely logical combinations of Leaf Processes. 
Furthermore, a Fxinction is merely a collective term for 
the logical organization of processes. For the purposes 
of software distribution, no description of software 

15 entity and relationship instances above Leaf Processes 
in a given software application is required. However, 
such higher level software entities (Function, Root and 
Node Processes) and their associated relationships are 
useful in conjxinction with software design efforts 

20 (referenced above) and could be present in such software 
^tity instance representations stored in the 
Repository 5. 

Regarding relationships depicted in Figure 3a, note that 
in Figure 3 c each interconnection between software 
25 entity instemces is represented by one of the Refines, 
Defines, Uses, Refers or Members relationship instances. 

For a given representation of applications software 
entity instances stored on the Repository 5, the 
specifics of each entity instance are recorded in the 
30 Repository 5. The Repository 5 as shown in Figure 3c, 
for example, contains entries not only for the 
identification of each entity instance, but for all 
attributes pertinent to that entity type. For example, 
stored sure the identification attributes of each Program 
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ins1:ance comprising tlae application, as veil as each 
Progreun and Da'ba En'tity instrance's exectrtion 
environmenl:. Furthermore, stored are the specifics of 
each relationship instance between entity instances, for 
5 example, the identity of each participant in a given 
relationship. In this way, any application aan be 
completely described. 

Besides containing a representation of a software 
application in terms of software entity axid relationship 
10 instemces, the Repository 5 also contains a 

representation of computer system heurdware in terms of 
instsmces of Workstation and Workstation Group entity 
types and their associated relationships- In addition, 
there is a description of which Workstation/Workstation 
15 Group instances have access to I^eaf Processes instances. 
This description is provided by the Workstation Group to 
Process (or Worlcstation to Process) relationship defined 
by the SDS Entity-Relationship Model. 

If the special entities and relationships which are 
useful with CASE euid other software are considered, a 
more detailed Repository 5 will be created. Figure 3d 
depicts a portion of an exemplary Repository 5 where 
program instances are replaced by Rule instances 30, 35, 
36, a Component instance 32 and a Window instance 31, 
and where specific data interfaces defined by a View 
instance 33 and Field instances 34 are included. Note 
that a View instance 33 and Field instances 34 do not 
replace or eliminate the need for the Data Entity 
instances emd Value instances or their associated 
relationships. Data Entity instances etnd Value 
instances have been omitted from Figure 3d for clarity. 

As indicated by Figure 3d, Window 31, Rule 30, 35, 3 6 
and Component 32 instances can share ownership of a View 
instance 33. However, Rule 30, 35, 3 6 and Component 32 
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instances may liave unshaxed isul'tlple View instances in 
addition to one wblch may be sheured. Also, as indicated 
in Figure 3d, a ^xven View instance 33 may Include more 
them one Field Instance 34* 

5 As is the case with the softwaure entity and relationship 
instances stored in the Repository 5, the hardware 
entity instemces and the hardware to softwsure 
relationship instances cure stored in the Repository 5 as 
part of the application software design process, or as 
10 part of the process of describing an existing 

application and system in terms of the SDS Entity- 
Relationship Model. 

By way of example. Figure 3e depicts the contents of the 
Repository 5 as they concern the hardware entity 

15 instances of a given system. The Leaf Process instcince 
11 shown in Figure 3e ccin be any of the Leaf Process 
instances shown in Figures 3c or 3d. Each Worlcstation 
dLnstance 3 can be any of the Workstations instances 3 
depicted in Figures 1 amd 2. The Workstation Group 

20 instsmces 17 are logical collections of dLndividual 

Worlcstation instajices 3. The Repository 5 identifiers 
individual Process instances by specific Process 
attributes stored for each Process instance, as 
discussed above. Similarly, all attributes generally 

25 stored for Workstation Group and Worlcstation dLnstemces, 
as defined by the SDS Entity-Relationship Model, aure 
stored in the Repository 5 for the specific system in 
c[uestion. Moreover, relationship types specified by the 
Model associating Processes with Workstation Groups and 

30 Workstation Groups with Workstations are stored in the 
Repository 5 as instances of these relationship types. 
Figure 3f depicts an exemplary portion of contents of a 
Repository 5 for systems which do not employ the 
Workstation Group entity type. As a consequence the 
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Reposit:ozy 5 s'tores no ins*tances of ent:i^ies or 
relationslixps associated with the Worlcstation Group. 

It shoxild be iznder stood tliat while the Repository 5 can 
and does contain copies of actual software entity 
5 instances which comprise the software application. 

Figures 3c-f depict a portion of the Repository 5 which 
contains a representation of the softwzure €uid hardware 
of the system by virtue of entity attributes • It is 
this representation of the softwsure and haordware entity 
10 instances, according to the Model, which is significzmt 
to the SDS process. 

The SDS Execution Environment 

Prior to proceeding with a discussion of the specific 
processing of SDS, a short discussion of the SDS 
15 execution enviroiunent will be useful. 

The two types of hardware configurations depicted in 
Figures 1 and 2 show three and two tiers of hardware 
platforms respectively. In either case however, it is 
preferred that SDS functions be executed on the 

20 mainframe processor 1, 7. This is because mainfreuae 
processors are best suited for dataibase-intensive 
processing. It should be understood that a mainframe 
processor, while preferred, is not an absolute 
requirement. Therefore, in the balEuice of this 

25 specification where reference is made "the processor (or 
node) executing SDS," it should be tinderstood to mean a 
mainframe only in a preferred embodiment. 

The discussion which follows also makes mention of some 
user interaction with SDS. Generally, this interaction 
30 occurs through user operation of a workstation. While 
such workstation could be any workstation 3 connected to 
the network, it is convenient that a special, workstation 
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or input/output device 6 be used for this purpose* 
Ttie impacrt Analysis 

After a representation of system software and hardware 
entity instsuices lias been stored in the Repository 5 as 
5 a combination of entity and relationship instances of 
the SDS Entity-Relationship Model, a programmer may make 
modifications to one or more software entity instances 
< e.q, , Programs, Data Entities, Rules, Components, 
Windows, etc.) comprising the application. At this 
10 point, SDS can be performed beginndLng with the SDS 
Impact Analysis. 

The Impact Analysis (lA) function of SDS determines what 
effect chfimges to certain software entity dLnstances will 
have on entity instances already defined in the 

15 Repository 5 and stored in the warehouse 4. The list of 
entity instances produced by the lA function, stored in 
an lA Table (lAT) of the Repository 5, will include all 
^tity instances directly modified by a programmer and 
will further dLnclude all entity instances which may need 

20 to be changed as a result of the direct modifications 
(propagated chsinges) . A programmer once informed of 
entity instances listed in the lAT must then consider 
these entity instances and make modifications to t- h ^^^-m 
where appropriate. 

25 The lA function could determine all directly modified 
entity instances simply by adopting a list of such 
entity instances provided by the progreunmer. However, 
it is preferred that a line-by-line comparison be made 
by the lA function between the unmodified application 

3 0 and the modified application, with all modified entity 
instsmces being noted in the lAT, 

The lA function determines possible propagated changes 
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by determining all Progaram instiances whidi call and 
whicti are called by tbe directly modified Program 
instsuices. SDS does this by scanning the Repository 5 
for all inst£Lnces of modified Program instances as 
5 either the First Participant or Second Participant 

attribute in Uses relationships • When such a situation 
is encountered, the corresponding Second or First 
Participant attribute Progreun instances respectively eire 
noted in the lAT. 

If the entities of View and Field are employed in the 
SDS Entity-Relationship Model for the application in 
question, SDS will scan the Repository 5 for all Program 
instances which Own Views Owned by the modified Program 
instances . These Program instances are then listed in 
the lAT. Also, SDS will scan the Repository 5 for all 
View instances which Include Field instances which eure 
defined to the modified Program instance. Then, all 
Progrsua instances which Own such View instemces are 
listed in the lAT. 

20 Whether or not the View/Field entities are used, the 
sccuining done by SDS is needed to help identify 
Program-to— Program data interfaces which may have been 
altered by a modification to one of the Progratm 
instamces* Any Program instance which calls or is 

25 called by a modified Progrsun instance, or which shares 
Views/Fields with a modified Program instsmce (Rule, 
component. Window) may have to be modified to account 
for changes to a data interface. 

The lA function of SDS also determines possible 
30 propagated changes by identifying all Data Entity 
instances which have been directly modified by a 
prograunmer and then by scajining the Repository 5 for all 
other Program instances which have access to (i*e. , 
Refer to) such Data Entity instances. This is performed 
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since a programmer may directly modify a Data Entity 
instamce by changing some aspect of data format^ but 
only account for sucb alteration in, say, tbe one 
Program instance Imown to the progreumner to have access 
5 to the Data Entity instance. However, becatise other 
Program dLnstances may also access the Data Enti*^ 
instance, these Program inst2mces may need modification. 

Thus, a programmer would have to consider all these 
additional Program instemces to determine whether 
10 modifications are required as a propagated effect of his 
direct modifications. The lA function, therefore, 
provides the prograunmer with information stored in the 
lAT of the Repository 5 which delineates the basic 
information needed to maJce such determinations. 

The above described lA function identifies all directly 
modified entity instances and all possible entity 
instances which may need to be changed as a result of 
direct modification (propagated changes) . An 
alternative form of lA, referred to herein as "IA2", 
identifies directly modified entity instances in the 
same way, but identifies entities requiring propagated 
changes in a different manner. Propagated changes sure 
determined changes based on the signif icemce of given 
direct modifications to other related entity instances. 
XA2 is premised upon the fact that a direct change to an 
entity instance may not affect the executsdDle form of 
other entity instances which would otherwise be 
identified by the lA function. These other entity 
instances, which may be numerous, need not be 
distributed by SDS. As a result, IA2 can provide a more 
efficient system for distributing softweure. 

IA2, like lA, identifies aLLl directly modified entity 
instzmces by, e.g., performing a line-by-line comparison 
of modified and unmodified applications. IA2, however. 
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goes fusrtliex' in ^a*t i't assigns a "Change Class" t,o 'bhe 
type of change made direcHly by the progrsumnez*. The 
Change Class is stored in the lAT for each directly 
modified entity instsuice. 

5 Change Classes are defined to dLndicate the significance, 
in terms of the extent of propagated effect of a given 
direct modification to an entity instance. For example, 
a Change Class of 01 might indicate a major propagation 
effect, while a Change Class of 02 might indicate a more 

10 modest effect, if any effect at all. Generally, a 

Change Class assigned to a modified entity dLnstance is a 
function of the entity attribute changed by the direct 
modification. Some entity attributes concern only the 
directly modified entity, while other attributes concern 

15 other entity instamces as well as the one modified. 
Depending on the nature of entity instcinces and their 
attributes. Change Classes may be defined to require no, 
some or many propagated chcuiges. 

For a given entity relationship model. Change Classes 
20 for an entity type are determined by considering the 
propagtive effect of changes to the attributes of the 
entity type. Thus, changes to each attribute of an 
entity type are considered for their propagative effect 
— the extent to which other entity types superordinate 
25 to the one in questions are affected by such changes. 

If changes to certain attributes of an entity type share 
a propagative effect, then such attrdLbutes are grouped 
together in a Change Class. 

The following tsOale (Table I) defines Change Classes for 
30 the entities of the Entity-Relationship Model useful 
with certain CASE software. The information presented 
in Taible I is used by IA2 to assign a change class to 
directly modified entities. 



BNSOOQO: <WO_910B542A1_I.> 



wo 91/08542 



PCT/LfS90/07011 



-36- 



10 



15 



Entity 

BnZ£ 

RDZiE 

COMP 
COMP 

WINDOW 

SET 

SET 
FTJD 

VIEW 



Change Clmss 
01 
02 

01 
02 

01 

01 

02 
01 

01 



T^IiB I 

Meaning 

Rule source code >>^^ changed. 

Rule KXKCENV or ASYNC fields 
have changed. 

Component source code changed* 

Component EXECENV or ASYNC 
fields have changed* 

Window source code or HEI*P file 
has changed. 

Set FORMAT, I.ENGTH, SCALE or 
SETVAL SYMBOL fields have 
chemged » 

SETVAL Relationship text has 
changed. 

Field FORMAT, LENGTH, SCALE or 
PIC STORAGE fields have 
changed. 

View VUOWNS field has changed. 



20 As shown in Teible I, the first column of information 

defines entity types. These entity types may have one 
or more Change Classes. As an exsuaple, the entity type 
"Set" appears twice axtd has, therefore, two Chemge 
Classes associated with it. (A Set is eui enumerated 

25 list of Values. Each Value is given a symbolic 
reference. A Set is defined by the following 
attributes: (1) Set Name, used to uniquely identify the 
Set; (2) Set Description, used to describe the Set 
instance; (3) Element Format, used to describe the 

30 format of Set elements; (4) Element Length, describing 
the length of the Set elements; (5) Element Scale, 
describing the number of decimal places for decdLmcO. 
fields; (6) SETVAL Symbol, describing the name of a 
given Vstlue in the Set). According to Tcible I, should 
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any of Uie Format:, I«engtii, Scale or SETVAI* Syoibol 
a^teibu^es diange, by virtue o£ a nodlfica-tion by a 
prograsD&er to tbe Set instance in qaestion, the Set's 
Change Class will be designated as 01. X£, on ^e other 
5 hand, the value of data represented by a given SETVAIi 
Symbol changes, the Chamge Clatss eissoclated with that 
Set is 02* 

The significance of a given Change Class to propagated 
changes is shown in Table IZ. 

10 TABLE II 

Propagative Effect Matrix 



20 



30 



•TYPE 


CSG 
CLA 


RUZi 


COM 


WIN 


ygw 


FLD 


SET 


PAREUT 
RPL COM 


TOP 
RUI. 


PRO 


RUIiE 


01 


Y 












N 




Y 


Y 


RUXiE 


02 


Y 












N 




Y 


Y 


COMP 


01 




Y 










N 


N 


Y 


Y 


COMP 


02 




Y 










N 


N 


Y 


Y 


WINDOW 


01 


N 




Y 








N 




N 


Y 


SET 


01 


Y 


y 


N 






Y 


N 


N 


Y 


Y 


SET 


02 


N 


N 


N 






Y 


N 


. N 


N 


Y 


FUD 


01 


Y 


Y 


N 


Y 


N 




Y 


Y 


Y 


Y 


VIEW 


01 


Y 


Y 


H 


Y 


N 




Y 


Y 


Y 


Y 


VAimiS 


01 


Y 


Y 


Y 






Y 


Y 


Y 


Y 


Y 



Table II indicates, for a given entity type with a given 
35 Change Class (first two columns) , other entity types 

(top of each column) , beginning with ("RUIi") which will 
feel a propagated effect from the changed entity • The 
"Y" entries in the taO^le specify the propagative effect, 
in terms of superordinate entity types, of changes to an 
40 entity inststnce listed in the "TYPE" column of the 
table. Depending on the attribute (of the entity 
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ins-fcance) directly modified, a given Cbange Class is 
Implicated (see Table I) . Specifically, for a modified 
Set with a Change Class of 01, Table II indicates, by 
virtue of the "Y" entries, that all Rules and Con^onents 
5 associated with that Set, and the Process, will 

eseperience a propagated effect (for example. Rules and 
Components will have to be reprepaured in executable form 
to account for the chemges in the modified Set) . in 
contrast, a modified Set with Change Class 02 need have 
only itself and the Process reprepared (see "Y" iinder 
"Set" and "Pro" column only) . That is. Rules and 
Components associated with that Set need not be 
reprepared. 

For every entry in the lAT indicating a modified 
software entity instauice, IA2 traverses Table II to 
determine iirtiich other entity types may be affected by 
the modification. In the case of a modified Set of 
Change Class 01, IA2 identifies the Rule, Component and 
Process entity types, IA2 then scans the Entity- 
Relationship representation of the software in 
Repository 5 to determine all entity instances of the 
identified entity types (e.g.. Rule, Component and 
Process Instances) which are related and superordinate 
to the modified entity instance in the software 
hierarchy of the Entity-Relationship representation. 
Each of these related entity instamces is identified in 
a table for later use in and testing and software 
^distribution. It may be that for any one entity 
Instance in the lAT, another entity instance is 
identified as having a propagated effect that has been 
identified previously. in this case, the entity 
Instance need not be identified a second time in the 
table. 

AS a result of IA2, a table is built, referred to as the 
35 IA2T, which includes all directly modified entity 
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izis'tances as well as all ins-tances which axe a resul't of 
the propaga-tion of direct: modifications. This table 
serves the SDS like the XAT discussed above. 

Sof^tvare Hodificaliion 
5 and lA Process Management 

In "berms o£ managing 'bJie software modification and XA 
processes (hereinafter, "lA" refers to either lA or IA2 
processes) , it is preferred that all Progrzun/Data Entity 
instance modifications, whether direct or propagated, 
10 occur not on the Repository 5 or the Warehouse 4 (which 
are actually "production" environments storing software 
and relational databases accepted as operational) , but 
rather on a "Development Repository" 5', This 
Development Repository 5' is either physically or 
15 logiccilly separate from other storage in the computer 
system in question and allows a programmer to make his 
direct modifications, and any necessary propagated 
modifications (as a result of lA) without the danger of 
contciminating existing storage. Thus, the Development 
20 Repository 5' contains the modified software 
application, as well as a modified entity and 
relationship representation of the software, if such is 
called for. It is preferred that the Development 
Repository 5' be connected to the mainframe processor 1, 
25 7 accessible through a Workstation 3, 6, however, it may 
simply be a data base local to a given Workstation 3 
connected to the network* 

It is further preferred that an lA be performed on a 
copy of the modified application stored in a "Staging 
30 Repository" 5", where application quality assurance 
testing can also be performed. Like the Development 
Repository 5', the Staging Repository 5" should be 
logically or physically distinct from other system 
storage and be connected preferably to the mainframe 1, 
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7. Also, tbe Steglng Repository 5" can be accessible 
througli amy processor/input-cutput combination, but is 
typically accessible, as is the Development Repository 
5% through a Workstation or Input/Output terminal 3, 6 
5 connected to the m ai nf rame l, 7. Generally, quality 
assuramce testing of a modified application requires 
installation of the application in executable form on 
its intended hardware environment (for example, a 
three-tiered environment) so that the software can be 
10 completely exercised. However, this testing activity in 
general does not require distribution of the modified 
software to more than one processor in a given trardware 
tier. 

Quality assurance testing is typically controlled from a 
15 single Workstation or input/ output device 3, 6 with 
access to the modified software stored on the Staging 
Repository 5". For purposes of identification, this 
Workstation or inpiut/ output device 3, 6 will be referred 
to as the "Quality Assurance Workstation"; it can be 
20 located amywhere in the system or network. Of course, 
quality assursmce testing requires that modified 
software entity instances be converted into executable 
form for use in testing by the various hardware 
platforms (tiers) of the system. 

25 As a result of an lA and quality assurance testing, 

further modification to the application may be required. 
If so, the further modification should be made 
preferably on the Development Repository 5', aoid lA and 
quality assurance testing should be repeated on the 

30 Staging Repository 5". It is preferred that repetition 
of the lA, quality assurance testing and Program 
modification sequence be contJLnued xintil quality 
assuremce testing indicates that the application 
fiinctions as desired. 
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Nhen all appropria1:e entity instance modifications liave 
been made and tested, it is further preferred that the 
modified and tested application, along with its entity 
and relationship representation, be moved to the 
5 Repository 5 for a final lA. Should this lA indicate no 
further difficulties, the modified application can be 
accepted for use as a "base line" or production version. 
(Shotild further modifications be required, it is 
preferred that they be made on the Development 
10 Repository 5' vith an XA and cpiality assursmce testing 
occurring at the Staging Repository 5".) 

At this point, a "Release" of the modified software 
entity instances can be built. Since as a result of a 
final satisfactory lA from the Staging Repository 5" to 

15 the Repository 5 both Repositories will contain copies 
of the same software instances and entity and 
relationship representation, it will be tmderstood that 
a Release could be built from either the Staging 
Repository 5" or the Repository 5. For purposes of 

20 explanation, it will be assumed that a Release will be 
built from the Repository 5. 

Building a Release 

A Release is defined as the logical unit of work to be 
distributed by SDS. This logical unit of work in effect 

25 is the total difference between the current version of 
an application as it exists in the Warehouse 4 ( i.e> , 
the unmodified version) and a modified application as it 
exists in the Repository 5 ( i^e. , all modified software 
entity instances) . The existence of each Release is 

30 recorded in a Release Entity TsQ^le (RET) in the 
Repository 5. 

A Release is described by a "Release Configuration" 
which is comprised in part of a Release-to-Entity 
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Relat:xonsiilp Table (RERT) scored in tiie Reposiliory 5. 
The R£RT contains an entry (or row) for each softvare 
entity instance to be distributed by SDS. 

The RERT Is coniprised in part of the list of all 
5 software entity instances affected by prograsmer 

modification. This list (or colmnn in the RERT) is the 
result of^ the SDS XA processing discussed above euid is , 
in effect, the lAT. 

The RERT is further comprised of a list of Physical File 
10 Names which will be identical to the list of modified 
entity instances except that should a modified entity 
instajice be comprised of more than one physical file, 
extensions are employed to augment the entity name thus 
separating dLndividual physical files associated with a 
15 single entity instamce. This list of physical files 
appears as a second column in the RERT. 

A third column in the RERT consists of Path Neuaes for 
each affected entity instance. A Path Name is chosen to 
be a fxinction of the attributes of a software entity 
20 instance. 

A fourth column in the RERT consists of Iiogical File 
Names which axe, as explained below, versions of 
Physical File Names which separate Physical Files on a 
Release basis. 

25 The Release Configuration is fiurther comprised of a 

Release to Process Relationship TadDle (RPRT) . Like the 
RERT, the RPRT is stored in the Repository 5. The RPRT 
contains an entry for all Leaf Process instances which 
are comprised in whole or in part of modified software 

30 entity instances. Entries to the RPRT are made by a 

scan of the Repository 5 for Process instsmces which are 
comprised of constituent softweure entity instances which 
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appeeir in ttie lAT for the Release. These assocxa-kions 
are provided by the Process to Program, Prograua to 
Program and Program to Data relationships discoissed 
2d30ve. 

5 Thus, for each Release (as indicated by each entry in 
the RET) there are entries in associated tables, the 
RERT and the RPRT. Each of these tables is stored in 
the Repository 5. Once entries to the RERT smd RPRT are 
made by SDS, the remaining activities required for 

10 software distribution are the incorporation of modified 
entity instances into the Warehouse 4 euid the physical 
transportation of individual software entity instances 
to their appropriate Workstations 3 ( i*e. , nodes to 
which software is to be distributed) . It is preferred 

15 that the performemce of these remaining steps be under 
the control of one centralized control mechanism, e.<?* , 
the mainframe 1, 7 of the three and two tiered computer 
systems of Figures 1 and 2, respectively (operated by a 
user at an associated worlcstation 6) • In this way, any 

20 issues concerning a Release which arise among system 

users who aore located at various worlcstations 3 can be 
dealt with in an orderly, organized fashion. Although 
these steps can be performed in a decentralized fashion, 
e,g, , by multiple controlling processors or by multiple 

25 users at Workstations 3 in the network, the centralized 
control approach is logistically simpler to implement. 

Incorporating Modified Entities into the 
Warehouse ^ - . 

At this point in the SDS process, modified software 
3 0 entity instcinces have been tested for validity and 
quality assurance, and entries to the RERT and RPRT 
tables have been made. The next step is the process of 
saving the modified software entity instances in the 
warehouse 4. 
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When software entity instances are saved in the 
Warehouse 4, they do not over-write or eliminate 
previously released versions of the seune entity 
instances. Rather, each modified entity instance is 
5 saved on a Release basis. To facilitate storage on a 
Release basis, SDS defines for each such entity instance 
a Logical File Name. Logical File Names are versions of 
entity Physical File Names contained in the RERT. 
Logical File Names are chosen as functions of both the 

10 Physical File Neu&e and the Release Name (from the RET) . 
SDS then creates em "Upload Order" containing a Logical 
File Name for each Physical Pile Name in a Release. An 
"Upload order Table" (UOT) is maintained in the 
Repository 5 to store status information about the 

15 processing of the Upload Order. 

The Upload Order is then transmitted over the network to 
the node which was responsible for the coordination of 
quality assxarzmce testing (the Quality Assurance 
Workstation) . This node, in response to this Order, 

20 collects the tested software entity instances, which aire 
in executable form, from the test nodes and transmits 
the software entity instsuices over the network to the 
node which controls the Waarehouse 4. The software 
entity instamces are then stored in the Warehouse 4 

25 under their Logical File Names as specified by the 

Upload Order. (Note that such modified software entity 
instauices could have also been sent from either of the 
Repositories 5, 5" to the Warehouse 4 depending on the 
embodiment chosen. However the Repositories 5, 5" may 

30 not have stored executable forms of the software entity 
instances. Should software entity instances be stored 
in non-execut£Q3le form in the Warehouse 4, they must be 
converted prior to execution on Workstations 3 . ) The 
Logical File Name generation process provides a distinct 

35 identity to every version of every entity instance 
stored in the warehouse 4. 
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When all software entity instances of the Release are 
stored in the Warehouse 4, the Upload Order is completed 
and an -Upload Complete" status is recorded in the UOT 
stored in the Repository 5. 

5 At this point, modified software entity instances can be 
distributed to the appropriate Worlcstations 3 (or nodes) 
by SDS. 

PH ysieal Software Distrib ution (Release Download) 

once a Release has been successfully uploaded to the 

10 warehouse 4 (so indicated by the Upload Complete status 
recorded in the UOT) , a Release Download can occur. In 
order to physically distribute software entity instances 
( i.e. . Download a Release) , it is necessary for SDS to 
determine which Workstations 3 are to receive particular 

15 modified software entity instances. This determination 
is made by SDS's scanning of the tables of the 
Repository 5 to associate modified software entity 
instances in a Release to their Process instances, and 
to associate such Process instances to particular 

20 worlcstations 3. specifically, the RPRT for the Release 
in question is scanned by SDS for all Process instances 
affected by the Release. SDS searches the Worlcstation 
Group to Process relationships of Repository 5 to 
determine those workstation Group instances which have 

25 access to the Process instances affected by the Release 
( i.e. , those Process instances in the RPRT; see Figure 
3e) . Furthermore, SDS searches the Workstation to 
workstation Group relationships of Repository 5 to 
determine those Workstations 3 which are members of the 

30 identified Workstation Group instances. (Should the 
particular computer system in question not employ the 
workstation Group entity, SDS would search the 
Repository 5 to determine directly those Workstations 3 
that have access to those Process entities affected by 
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l:Ixe Release by virtue of tbe Worksliatlon to Process 
relation sh 1 p . } 

this poin^t, a logical rela^ionsliip has been made 
between Wor]cs1:a*tions 3 and Process instances affected by 
a Release. SDS then scans the RERT to determine all 
entity instiances affected by the Release, Furthezssore, 
SDS sc2ais the Repository 5 to determine all Process 
ins*tances which are comprised of such entity instances* 
This is done by "tracing, for each such entity instance 
in the Release (as indicated by the RERT) , a path 
upwsurds in the softweure hierarchy, through the 
relationship eoid entity instemces stored in the 
Repository 5 (see Figure 3c) , until each Process 
instance is identified. The Repository 5 therefore 
provides the association between Processes in the 
Release etnd affected entity instsmces. 

The logical relationship between Workstations 3 and 
Process instances affected by a Release, together with 
the logical relationship between Process instances 
20 affected by a Release and affected entity instemce, 
provides the basis for the creation of specific 
"Download Orders.** 

A Download Order is built by SDS for each affected 
Workstation 3. A Download Order (DO) is a list of the 

25 modified software entity instemces for each Workstation 
3 identified in the technique described above. Each 
modified software entity instsmce is identified in a DO 
by its Physical File Name, Logical File Name and its 
Path Neuae. Each DO is identified by a specific DO 

30 Number. The DO's sure then sent by the node executing 
SDS through the computer system network for storage at 
each affected Workstation 3. A "Download Order TsJDle" 
(DOT) is maintained by the Repository 5 to st.ore status 
inforsia1:ion eissociated with the processing of DOs. 
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Each affected Works'ba'kion 3 processes a DO In peurt by 
retrieving all specified so£t%rare entity instances (by 
Logical File Neme) from the Weurehouse 4 into its ovn 
local wsurehouse database. The local warehouse is 
5 storage which ist ancillary to that used for storing 

baseline versions of softweure entity instances executed 
by the Worlcstation 3. The downloaded softvsure entity 
instances are saved in the locetl wsurehouse under the 
same LogiceLL File Names as used in the warehouse 4. It 

10 is preferred that such entity instances be saved in a 
compressed file (to save space) identified by the 
associated DO Number. It is further preferred that each 
Workstation which has stored modified entity instances 
(in its local warehouse) pass a completion status back 

15 through the network to the node executing SDS for 
storage on the DOT in the Repository 5 to reflect 
completion of the Download process. At this point, the 
Release ( i>e. , modified software entity instamces) has 
been distributed or "downloaded" to those Workstations 3 

20 which require updating. 

Release Installation 

After modified softwcire entities have been downloaded to 
a Workstation's local warehouse database, installation 
of such entity instcuices can occxir at the appropriate 

25 time. Typically modified software entity instances are 
installed for use on every Workstation 3 (that has 
received the downloaded software entity instances) at 
the Scime time. The time chosen should correspond to 
when such Workstations 3 are not executing the 

3 0 tinmodified application. 

SDS provides for installation of modified software 
entity instances through the generation of Install 
Orders in response to user instructions to install a 
Release. SDS generates its Install Orders by first 
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searching tlie DOT for tHe Zielease in question in the 
Repository 5 to determine all WorJcstations 3 tliat Ixave 
received downloaded software ( i.e. , Download status 
checked). Next, SDS constructs the Install Orders. 
5 These Orders are sent over the network to each 

identified Worlcstation 3. (Note that in a three tiered 
system, the mini-coaiputer 2, receives the Install Orders 
from the mainframe 7 (which is executing SDS) and 
directs them to the individual Wor]cstations 3 over the 
10 network. However, in a two tiered system the mainframe 
1, 7 both generates and directs such Orders to the 
appropriate WorJcstations 3.) Each Install Order 
contains a number which matches the DO Number previoxisly 
received by the Workstations 3. SDS maintains an 
15 "install Order Table" (lOT) in the Repository 5 to store 
status information associated with the processing of 
lOs. Prior to executing each Install Order, each 
Workstation 3 saves (or "backs out") previous versions 
of modified software entity instances and store them in 
20 compressed a file. This compressed file is preferably 
identified by the DO Number with an extension indicating 
its status as a back out file. The entity instances to 
be backed out are identified by the Workstation 3 by 
reference to the DO it heis previously received and 
25 stored. 



Once in receipt of an Install Order, and after having 
backed out previous versions of the jnodified software 
entity instances, a Workstation 3 can install the 
modified software entity instances for regular baseline 

0 application processing. The installed entity instances 
are saved preferably \inder their Physical File Names 
listed in the DO for the Workstation 3. They are stored 
at an address identified in part by their associated 
Path Names (also indicated in the DO) . With instal- 

5 lation completed, an "Installation complete" status is 
returned by the Workstation 3 in question and this 
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infornation is saved in the lOT of the Repository 5. 

The backed out entity instamces stored in the 
Workstation local warehouse have use when it is 
desirable to restore a prior Release. To accoa^lish 
5 this, SDS issues a Back Out Order to all affected 

Workstations 3. The Back Out Order includes a DO Number 
associated with the Release to be backed out (i.e. , de- 
installed) . The compressed file stored on the local 
warehouse identified by the corresponding DO Nuinber 
10 (with a backout extension) is then xised as the file to 
be installed at the Workstation 3 for baseline 
processing. 

For pTirposes of Release Downloading, Installation and 
Back-out, it is preferred that Workstations 3 have a 

15 time interval designated during which such activities 
can occur. This can be achieved in several ways 
including the creation of an "SDS Mode" for each 
Workstation 3 in waich each can process Download, 
install or Back-Out Orders. The "SDS Mode" could occur 

20 at a designated time or at various times determined by 
SDS (in the latter situation, SDS could issue an SDS 
Mode command to the various Workstations 3 in the 
network informing them of when to switch to SDS Mode and 
for how long to remain in the Mode) . 



25 sn-m^arv of Detailed Description 

The representation of computer system entity instances 
and the relationships between such instances as stored 
in the Repository 5 as a result of software design, as 
well as the construction of special relationships stored 
30 in tables in the Repository 5 for the purposes of 

software distribution, are sxjmmarized by way of example 
in Figure 4. Figure 4 depicts the modified software 
entity instances (programs 18 and Data 19) which are the 
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resi2l*b of dlrecrt and propagated modlf Ica'tlons to the 
software entity Instances. All such modified entity 
Instances, vliether of tbe direct or propagated type, 
originate in the Development Repository 5'. The need 
for propagated modifications is identified by an lA and 
quality assurance testing, both associated with the 
Staging Repository S**. (Should propagated modifications 
be indicated, these sure generated back at the 
Development Repository 5 ' . ) Whether resulting from 
direct or propagated modifications, all modified entity 
instances aore listed in a table (XAT) as a result of the 
XA. Quality assurance testing associated with the 
Staging Repository 5" occxirs with modified entity 
instances in executable form. 

When quality assurance testing is completed, a Release, 
described by a Release Configuration, can be built by 
SDS« A Release Conf igxiration is based on two tables, 
the RERT and the RPRT. The RERT associates Physical 
File Neimes and Path Ncimes with each entity instance to 
be distributed by SDS. The RPRT associates with the 
Release all affected Leaf Processes 21. 

To distribute softweore, SDS issues certain orders to 
various nodes in the network. One of these is the 
Upload Order, issued to the node controlling the 
25 Warehouse 4, to collect and store software modified 
entity instances under a Logical File Name. 

Another of these is the Download Order, issued to 
Worlcstations 3, to retrieve from the Warehouse 4 
particular modified software entity instances and store 
30 them in a local warehouse under Logical File Names. The 
DOS are constructed by SDS from a scan of the RERT, 
RPRT, and the softweure and hardware entity and 
relationship instance representations maintained by the 
Repository 5. 
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In order to implement a Release Configuration f i>e^ ^ 
install a Release) , Install Orders are created by SDS 
and sent to all affected Worlcstations 3» The 
Worlcstations 3 Implement the Install Osrders by saving 
5 previous versions of entity instances and by inststlling 
newly modified entity instances. 
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In the Claims ; 

1. A xnethod for distributing software in a 

coarputer system, the software comprising one 
or more software enti^ instances ^T t ^f the 
computer system comprising one or more 
hardware entity instances, the method 
cos^rising the steps of: 

storing information in a database 
descriptive of the softwsure entity 
instances, hardware entity 
dlnstances, and relationship 
instances between such hardware 
and software entity instances; 

modifying one or more software 
entity instances; 

scanning the dat2ibase to associate 
with each modified software entity 
instsoice one or more hardware 
entity instemces to receive each 
such modified software entity 
instance ; and 

distributing one or more modified 
software entity instances to one 
or more associated hardware entity 
instances . 

2. The method of claim 1 wherein the step of 
storing information is performed according 
to an entity-relationship model. 
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3 • The metihod of claim 1 vhezreln ^the softrvaiire 
entzl'ty insluuices comprise one or more 
progreun Ins'tances. 

4. The me-thod of claim 1 herein -bhe sof*tvare 
ent:l^y ins*tances comprise one oz^ more data 
entity instamces. 

5. The method of claim 1 further including the 
step of: 

storing one or more modified 
software entity instances in a 
database ; and 

wherein the step of distributing one or more modified 
software entity instajices comprises: 

commtini eating one or more modified 
software entity instances from 
said datcibase to one or more 
associated hardware entity , 
instances • 

6* The method of claim 2 wherein the entity- 
relationship model comprises entity and 
relationship types, the entity types 
comprising: 

value, which describes a datum; 

data entity, which describes a set 
of one or more values; 

program, which describes a 
software routine; 
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process, whic h describes a set of 
one or more programs; and 

vorlcstatlon, viilch describes a 
liardware node In a cosipu'fcer 
system; 

the relationsbip types coarprising: 

data entity to value, which 
describes the association of a 
value to a data entity; 

program to data entity, which 
describes the association of a 
data entity to a program; 

program to program, which 
describes the association of a 
program with another program; 

process to program, which 
describes the association of a 
program to a process; and 

workstation to process, which 
describes the association of a 
process to a worlcstation. 

7. The method of claim 6 wherein the stored 
information comprises : 

a process instance; 

one or more program insteinces; 

one or more process to program 
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relatxonship Ins-tances, each such 
3relat:±onslilp lnst:€mce irela^lng a 
p ro gr a m iiis*b£mce to the process 
ixistemce ; 

one or more workstation Instances; 
suid 

one or more workstation to process 
relationship instances, each such 
relationship instcince relating a 
workstation instcuice to the 
process instance . 

8. The method of claim 7 wherein the stored 
information further comprises: 

one or more data entity instances; 

one or more value instances; 

one or more data entity to value 
relationship instances, each such 
relationship instance relating a 
data entity instance to a value 
dLnstance ; and 

one or more program to data entity 
relationship instances, each such 
relationship instance relating a 
prograun instance to a data entity 
instance . 

9. The method of claim 6 wherein the program 

entity type comprises a male entity type and 
wherein the process to progrcim relationship 
type comprises a process to rule 
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relaliionsliip ^ype. 

). The method of claim 9, wiiereln the ^red 

iJi£onaa'k±on comprises; 

a process instiance; 

one or more rule insliances; 

one or more process to rule 
relationsliip instances^ each such 
^®l^*ionsliip instance relating a 
rule instance to the process 
instance ; 

one or more workstation instances; 
and 

one or more worJcstation to process 
relationship instances, each such 
^^^^"tionship instance relating a 
worJcstation instance to the 
process instance. 



11- The method of claim lo, wherein the program 
entity type further comprises a component 
entity type and wherein the program to 
program relationship type comprises a rule 
to component relationship type and wherein 
the stored information fxirther comprises: 

one or more component instcinces; 
and 

one or more rule to component 
relatioxiship instances, each such 
relationship instance relating 
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each component: ins-tamce to a rule 
inst:ance • 

12. The me'khod of claisi XO, vheredLn -bhe progzaoi 
entity type further coioprises a vindov 
entity type and wherein the program to 
program relationship type comprises a rule 
to window relationship type ajid wherein the 
stored Information further comprises: 

one or more window Instemces; and 

one or more xxile to window 
relationship instances, each such 
relationship instance relating a 
window Instance to a rule 
instance. 

13. Xn a mass storage device, a database for 

storing Information according to an entity- 
relationship model, the database for use in 
distributing softwaore in a computer system, 
the model comprising entity and relationship 
types, the entity types comprising: 

value, which describes a datum; 

data entity, which describes a set 
of one or more values; 

program, which describes an 
Individual software routine; 

process, which describes a set of 
one or more programs; and 

workstation, which describes a 
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hardvare node in a cQnqpu^er 
system; 

tile ralationsh ip -bypes coosprising: 

da^ en^l^ -bo value, vlilcti 
describes tiie eissocia^xon of a 
value ^o a da*ba entil'ky; 

program to data entity, vlilcli 
describes tbe association of a 
data entity to a program; 

program to program, wliicti 
describes the association of a 
program with etnother program; 

process to program, which 
describes the association of a 
progreun to a process; cind 

workstation to process, which 
describes the association of a 
process to a workstation. 

14. The database of claim 13 wherein each entity 
type of the model is described by a set of 
attributes, the set of attributes for a 
progrcUtt comprising a identifier attribute 
and 201 execution environment attribute. 

15. The datcibase of claim 13, wherein the 
information comprises : 

a process instemce; 

one or more program instances; 
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one or more process 'bo progrsua 
rela'blonsliip xns-bances, each such 
rela-tlonship ins'tsuice relating 
each progrsua instance to the 
process inst£uice; 

one or more workstation instamces; 

one or more workstation to process 
relationship instcinces, each such 
relationship instance relating 
each workstation inst«mce to the 
process instance. 

16. The database of cladLm 15, wherein the 
information further comprises: 

one or more data entity instances; 

one or more value instances; 

one or more data entity to value 
relationship instances, each such 
relationship instsmce relating a 
data entity instance to a value 
instemce ; and 

one or more program to data entity 
relationship instances, each such 
relationship instsince relating a 
progrcim instance to a data entity 
instance . 

17. The database of claim 13 wherein each 
relationship type of the model is described 
by a set of attributes, the set of 
attributes for each relationship including a 
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first partlcipemt and a second participant. 

18 • THe database of claim 13 wlierein the program 
«*tity type cosKprisas a rule enti^ type and 
herein tlie process to program relationship 
. I^ype comprises a process to rule 
relationship ^^pe. 

19. The database of claim 18^ wherein the 
information comprises: 

a process dLnstamce; 

one or more rule instances; 

one or more process to rule 
relationship instances, each such 
relationship inst€aice relating 
each rule instance to the process 
instatnce ; 

one or more workstation instances; 
and 

one or more workstation to process 
relationship instemces, each such 
relationship instance relating 
each worlcstation instemce to the 
process instance. 

20. The datcOsase of claim 19, wherein the 
program entity type fxirther comprises a 
component entity type amd wherein the 
program to program relationship type further 
comprises a rule to component relationship 
type and wherein the information further 
comprises : 
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one or more component: ins'teuices; 
and 

one or more snile to component 
rela'tionship instancBs, each such 
relat:lonship instance relating 
each component instance to a rule 
instemce • 

21. The dat£Q^ase of claim 19, wherein the 

program entity type further comprises a 
window entity type and wherein the progreun 
to program relationship type further 
comprises a rule to window relationship type 
emd wherein the information further 
comprises : 

one or more window instances; atnd 

one or more window to rule 
relationship instances, each such 
relationship instance relating 
each window instance to a rule 
instance. 
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